Mastering Ansible by James Freeman and Jesse Keating

Mastering Ansible by James Freeman and Jesse Keating

Author:James Freeman and Jesse Keating
Language: eng
Format: epub
Publisher: Packt Publishing Pvt Ltd
Published: 2021-10-27T00:00:00+00:00


Using the rescue section

The rescue section of a block defines a logical unit of tasks that will be executed should an actual failure be encountered within the block. As Ansible performs the tasks within a block, executing from top to bottom as it normally does, when an actual failure is encountered, execution will jump to the first task of the rescue section of the block (if it exists; this section is optional). Then, tasks are performed from top to bottom until either the end of the rescue section is reached or another error is encountered.

After the rescue section completes, task execution continues with whatever comes after the block, as if there were no errors. This provides a way to gracefully handle errors, allowing cleanup tasks to be defined so that a system is not left in a completely broken state, and the rest of a play can continue. This is far cleaner than a complex set of task-registered results and task conditionals based on the error status.

To demonstrate this, let's create a new task set inside a block. This task set will have an unhandled error in it that will cause execution to switch to the rescue section, from where we'll perform a cleanup task.

We'll also provide a task after the block to ensure execution continues. We'll reuse the error.yaml playbook:

---

- name: error handling

hosts: localhost

gather_facts: false

tasks:

- block:

- name: delete branch bad

ansible.builtin.command: git branch -D badfeature

args:

chdir: /srv/app

- name: this task is lost

ansible.builtin.debug:

msg: "I do not get seen"

The two tasks listed in the block section are executed in the order in which they are listed. Should one of them result in a failed result, the following code shown in the rescue block will be executed:

rescue:

- name: cleanup task

ansible.builtin.debug:

msg: "I am cleaning up"

- name: cleanup task 2

ansible.builtin.debug:

msg: "I am also cleaning up"

Finally, this task is executed regardless of the earlier tasks. Note how the lower indentation level means it gets run at the same level as the block, rather than as part of the block structure:

- name: task after block

ansible.builtin.debug:

msg: "Execution goes on"

Try executing this playbook to observe its behavior; add verbosity to the output as we have throughout this chapter to help you understand what is going on. When this play executes, the first task will result in an error, and the second task will be passed over. Execution continues with the cleanup tasks, and should look as in Figure 7.13:



Download



Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.